Nowadays, the Internet is widely used to transfer applications to users using browsers. The Internet also is used for commerce on the Web in which individual customers and businesses use the Web to purchase various goods and services. In fact, some companies offer goods and services solely on the Web while others use the Web to extend their reach.
With respect to these commercial activities and others, businesses and other content providers employ servers to process requests from different users. Various architectures are employed in handling these requests. Often, distributed architectures in which a set of servers in a cluster (“server farm”) are used to handle requests. In such a server farm system, the set of servers appears to a user as a single server. A load-balancing mechanism may be used to determine which server within the server farm will be used to handle various requests directed to the server farm.
Configuring and maintaining the various servers within a server farm has historically been a difficult task. This problem is exacerbated as the number of servers employed in a given server farm increases in number. In order to properly maintain servers within a server farm, the servers need to be updated from time to time. These updates include configuring data and services provided by the servers, ensuring certain settings of each of the servers are in sync with respect to each other, and maintaining near real-time knowledge of the various services and applications that exist on the servers of the server farm.
Unfortunately, current technologies that perform server management fail to provide a cohesive methodology for enabling systematic and comprehensive management of servers within a server farm. For example, conventionally, most applications store configuration data in files. Such an approach has several key problems. First, these configuration files need to be kept in sync among all servers running the applications. Technologies such as Microsoft's Application Server manage to keep the configuration files in sync across multiple servers by copying the configuration files among the servers. However, a lot of additional work is necessary to provide server-specific information when copying the configuration file to a server machine. Therefore, it is desirable to have a mechanism that centrally stores all configuration data for a server farm and makes configuration data for an application automatically available everywhere in a server farm.
In addition, when one application is built on the top of another application (“base application”), the application needs to be aware that the base application has its own file format and the application usually needs to store its settings in a separate file. Though technologies such as XML make file formats more easily extensible, such technologies require the base application to publish a schema and a mechanism to prevent different applications from extending that schema in incompatible ways. Furthermore, if the base application wishes to upgrade settings stored in XML, the base application needs to ensure that it does not incidentally alter the settings of other applications or settings upon which those applications depend. Similarly, the base application can never change the locations of the files that contain the settings of applications depending on the base application. Another popular design stores application settings in a registry on each machine. This design makes it virtually impossible to distribute settings across a server farm and can have an adverse impact on system resource usage. Therefore, it is desirable to provide a centralized, extensible mechanism for storing application settings that does not rely upon a fixed file format.